What type of PR is this?

• API-change
• BUG
• Improvement
• Documentation
• Feature
• Test and CI
• Code Refactoring

Which issue(s) this PR fixes:

Closes #25690

Related to #25691.

What this PR does / why we need it:

Remote pipeline completion currently couples a logical stream teardown to destruction of its morpc backend and CN-to-CN TCP connection. High-fanout distributed queries therefore create enough connection churn and TIME_WAIT tuples to exhaust Linux ephemeral ports even though the CN processes remain healthy.

This PR adds a negotiated FIN/FIN_ACK lifecycle for successfully drained pipeline streams:

• the client requests FIN/ACK teardown per stream and falls back to the legacy close-connection path when the server does not accept it;
• the server acknowledges FIN only after pipeline and dispatch cleanup crosses a completion barrier;
• morpc atomically retires sent/received sequence state before unlocking the still-exclusive backend for reuse;
• uncertain FIN delivery, timeout, malformed sequencing, unread data, cancellation, and ambiguous errors poison and close the backend;
• lifecycle, FIN/ACK, reuse, close-reason, and sequence-container metrics make teardown outcomes observable;
• disable-stream-reuse provides a rollback switch.

The connection remains exclusively locked while a logical stream is active. This PR does not multiplex active streams on one TCP connection, add query-boundary admission, or change the existing maximum-concurrency policy. Those require separate deadlock/fairness design under #25691.

Validation

• go test -count=1 ./pkg/common/morpc ./pkg/cnservice ./pkg/sql/compile
• targeted FIN/ACK, lifecycle, and negotiated teardown tests with -race
• make -j8 build
• macOS two-CN reproduction: two consecutive 400-statement waves completed 400/400 with result 499999; CN pipeline TIME_WAIT remained zero
• Linux amd64 with independent log/TN/CN1/CN2 processes: two consecutive 400-statement waves completed 400/400; established socket endpoints plateaued at 2,778 then 2,814; TIME_WAIT remained zero during load; idle GC returned established pipeline sockets to zero and CN file descriptors from about 2,895 to 63
• both CNs remained healthy, and the exact join still returned 499999 after idle GC

The design, failure matrix, rollout/rollback plan, and detailed acceptance records are included in docs/design/cn_pipeline_connection_lifecycle.md.